home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20030409-20031118 / 000256_icurmtdude@yahoo.com_Thu Sep 4 10:55:04 EDT 2003.msg < prev    next >
Text File  |  2020-01-01  |  2KB  |  68 lines
  1. Article: 14496 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!panix!newsfeed.media.kyoto-u.ac.jp!newsfeed.icl.net!newsfeed.fjserv.net!diablo.theplanet.net!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail
  3. From: icurmtdude@yahoo.com (icurmt)
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: Re: missing bytes...
  6. Date: 4 Sep 2003 07:40:06 -0700
  7. Organization: http://groups.google.com/
  8. Lines: 49
  9. Message-ID: <cf6cc183.0309040640.11263a4b@posting.google.com>
  10. References: <cf6cc183.0309031713.73a00933@posting.google.com>
  11. NNTP-Posting-Host: 24.97.119.28
  12. Content-Type: text/plain; charset=ISO-8859-1
  13. Content-Transfer-Encoding: 8bit
  14. X-Trace: posting.google.com 1062686407 18505 127.0.0.1 (4 Sep 2003 14:40:07 GMT)
  15. X-Complaints-To: groups-abuse@google.com
  16. NNTP-Posting-Date: 4 Sep 2003 14:40:07 GMT
  17. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:14496
  18.  
  19. Looks like the INPUT (\v(input)) operations discard and ignore NUL
  20. characters that arrive from the communication device. Is there any way
  21. that can be turned on or use some other operation instead of INPUT.
  22.  
  23. Ray
  24.  
  25. icurmtdude@yahoo.com (icurmt) wrote in message news:<cf6cc183.0309031713.73a00933@posting.google.com>...
  26. > Hi everyone,
  27. > 
  28. > After no luck with this issue, I thought of posting it here.. Heres
  29. > what I am trying to do..
  30. > 
  31. > I am sending out commands out of a file through serial port to my
  32. > application which returns me the response accordingly in return..
  33. > 
  34. > <code snippet...> 
  35. > ..
  36. > ...
  37. > transmit /binary /noecho /nowait <commandsfile>
  38. > input 1 -1
  39. > .output := \fhexify(\v(input))
  40. > echo \m(output)
  41. > ...
  42. > fopen /write \%c <outputfile>
  43. > ..
  44. > fwrite /line \%c \m(output)
  45. > ..
  46. > fclose \%c
  47. > 
  48. > </end>
  49. > 
  50. > The script works fine. The response as under is outputted to the
  51. > 'outputfile'. Now when I echo the response I get
  52. > 
  53. > 16 06 14 34 47 12 01 87 
  54. > instead of 
  55. > 16 06 14 34 47 12 00 01 87 00 00 00
  56. > 
  57. > Note the difference after the 6th byte. The 7th and 8th byte which is
  58. > 00 01 shows up as 01 and 10th, 11th and 12th bytes do now show up at
  59. > all. However I have had success getting bytes in the order such as
  60. > below and echoing this command works fine.
  61. > 16 06 14 34 46 11 00 00 BB 10 00 00 
  62. > 
  63. > If anyone has any idea of whats going on here then please help me.
  64. > 
  65. > Thanx,
  66. > 
  67. > Ray
  68.